Peripheral integrated circuits (ICs) are often connected to a central processing unit (CPU) as memory-mapped input/output (I/O) devices using a parallel bus for each of address and data. Unfortunately, routing parallel buses, along with required address decoders and other interface logic, on a printed circuit board (PCB) results in a complex and expensive PCB, which is not viable in mass-produced products such as television sets, video cassette recorders and audio equipment. In these products, every PCB that can be simplified and every component that can be omitted results in increased profitability for the manufacturer and more affordable products for the customer. In addition to the problems of cost and complexity, the greater numbers of wires that constitute a parallel bus renders the CPU and peripheral devices more susceptible to disturbances by electromagnetic interference (EMI) and electrostatic discharge (ESD).
To address these problems, Philips Semiconductor developed the I2C bus in the early 1980s to provide a less expensive and simpler way to transfer data between or among a CPU, such as a microcontroller, and one or more peripheral devices. Rather than being a parallel bus, the I2C bus is a serial bus having only two wires (assuming a common ground among CPU and peripheral devices). One wire, called “SCL,” bears a clock signal; the other wire, called “SDA,” bears the data. Data is transferred among a “master device” (typically the CPU) and various slave devices (typically the peripheral devices) in a “transaction” that consists of a “start condition,” a preamble, the data, a “stop condition” and various acknowledgement signals. A transaction in which data is read from a peripheral device is called “reading;” a transaction in which data is written to a peripheral device is called “writing.” A single I2C serial bus can replace both address and data parallel buses. Today, the I2C bus is used in many applications other than just audio and video equipment. Industry has accepted the I2C bus as a de facto standard.
Although I2C buses are flexible and inexpensive, each data transfer transaction necessarily involves a delay (expressed in terms of clock cycles) for transferring the preamble. For example, the preamble for reading data requires 29 clock cycles. This delay is properly characterized as overhead and limits the rate at which data can be transferred over an I2C bus. For example, if a given transaction calls involves the reading of 8 bits of data, almost 75% of the bandwidth of the bus is occupied with overhead.
This bus data rate limit is particularly disadvantageous in the context of production testing, when data is often required to be read from one or a relatively small group of addresses many times over in order to test equipment before it is shipped. Because the transfer is repeated, the 18 or 29 clock-cycle overhead is incurred over and over again, compounding it into a significant delay. As a result, tests may not be performed as often or thoroughly as desired. Other tests may not be possible at all given the limited data rate.
Accordingly, what is needed in the art is a way to enhance the data rate of an I2C bus. What is further needed in the art is a way to decrease the amount of overhead incurred in repeated transfers involving one or more addresses.